\subsection{Menus}
	\subsubsection{API et widget}
	\paragraph{Android\\}
		Afin de créer les différents menus de notre application, Android met à la
		disposition des développeurs une \gls{api} très bien fournie. Parmi celle-ci le package \gls{widget}
		nous a été très utile. 
		
		Grâce à ce dernier de nombreux objets ont été utilisés
		afin de mettre en oeuvre et rendre pleinement fonctionnel nos menus.
		Parmi les plus utilisés il y a eu bien sûr: Button, TextView, CheckBox et
		EditText pour les plus explicites. Les objets comme Spinner, SeekBar et
		Gallery étant respectivement utilisés pour les menus déroulants, les barres de
		progression et les galeries d'images pour la sélection de cartes de jeu.
		
		Les composants graphiques sont créés ici au travers du fichier déclaratif
		\gls{xml} via une synthaxe bien particulière. Cette méthode est vraisemblablement
		préférable, du moins lorsque l’interface graphique est figée, connue à l’avance. 
		Exemple :
		\begin{verbatim}
		
		<Spinner android:layout_width="wrap_content"
				 android:layout_height="wrap_content"
				 android:id="@+id/accounts"
				 android:layout_gravity="center_horizontal"
				 android:prompt="@string/ChooseUserAccount"></Spinner>
				
		\end{verbatim}		
		
		
		Pour récupérer la référence d’un widget créé depuis le
		fichier \gls{xml} de layout, il convient d’utiliser la méthode findViewById de la
		classe Activity dans nos classes Java.
		
		
		Exemple :
		
		\begin{verbatim}
			Spinner sp = (Spinner)findViewById(R.id.accounts);
		\end{verbatim}
		
		On peut remarquer que cette méthode accepte en paramètre un entier et non une
		chaine de caractère  comme on pourrait s’y attendre. En effet, l’identifiant est exprimé sous forme de constante entière (int), on
		ne passe pas à la méthode la chaîne de caractères proprement dite. Grâce à cela, la
		méthode est sûre et on évite ainsi les erreurs à l’exécution qu’on pourrait avoir si on
		spécifiait un id ne correspondant à aucun widget.
		
		Concernant leur positionnement, un système de layout est utilisé. Les layouts sont des ViewGroup responsables
		du dimensionnement et du positionnement des widgets à l’écran. Il en existe plusieurs, 
		chacun adoptant une stratégie bien spécifique. 
		
		En ce qui nous concerne nous avons principalement utilisé les
		\textit{ListView, LinearLayout, TableLayout} et enfin les \textit{RelativeLayout}. Ce dernier nous a été très utile. En
		effet les widgets contenus dans un RelativeLayout peuvent déclarer leur position relativement
		par rapport à leur parent ou par rapport aux autres widgets. De ce fait nos
		menus et autres interfaces graphiques conservent leur proportion et leur
		agencement originel.		
		
		
		Les écouteurs présents dans les classes java permettent à leur tour d'écouter les évènements utilisateurs
		ou systèmes et réagir en fonction, comme l'accès au menu suivant ou le lancement
		d'un partie. 
		
		
		Les activités sont des composants centraux des applications. Ce sont également les
		composants qui portent les éléments visuels de l’interface utilisateur agencés
		sur l’écran. La navigation entre les écrans se fait dans notre cas de façon
		explicite. L’ordre de changement d’activité est véhiculé par un objet de type Intent (intention en anglais).
		Les activités s’enchaînent les unes aux autres par invocation directe.
		C’est-à-dire qu’une activité donnée déclenche l’affichage d’une autre activité 
		en appelant la méthode startActivity avec un Intent mentionnant clairement le nom
		de l’activité. 
		
		Voici un exemple représentant la cohabitation listener Activity:
		
		\begin{verbatim}
		private Button create;
		this.create = (Button)findViewById(R.id.SinglePlayerGame);
		this.create.setOnClickListener(this);
			
		public void onClick(View view) {
		       Intent intent = null;
		       if( view == create ){
		             intent = new Intent(SinglePlayer.this, SinglePlayerLayout.class);
		             startActivity(intent);
		             this.finish();
		       }
		}
		\end{verbatim}
		
		
		
		
		
		
	\paragraph{iOS\\}
		
	Comme Android, nous avons utilisé les widgets pour réaliser notre interface graphique. iOS fournit lui aussi une API couplée à une documentation très complète facilitant la réalisation d'une interface utilisateur ergonomique. Parmi les widgets les plus utiles, nous retrouvons les UIView, UITableView, UITableViewCell, UILabel, UITextField, UIButton qui permettent respectivement de créer une vue, un tableau, une cellule du tableau, des labels, des champs de texte et des boutons.
	
	Pour manipuler ces différents composants graphiques, il est possible et beaucoup plus pratique d'utiliser Interface Builder pour réaliser des menus. Interface builder permet de gagner du temps lors de la réalisation d'une interface graphique standard (de type menu). Cette réalisation est possible via un outil visuel et non des lignes de code,  Interface Builder va créer des fichiers \gls{xib} qui vont générer à la compilation des fichiers \gls{nib}. Ce dernier stock les informations relative à l'interface sous forme d'un fichier \gls{xml}. Nous n'avons pas besoin de savoir réellement comment cela fonctionne car il est inutile de modifier directement le fichier \gls{xml}.
	
	Ensuite pour contrôler les différents éléments de l'interface préalablement créés avec Interface Builder, il suffit de les lier au code de la vue via ce dernier. Grâce à ces liaisons, il nous sera possible de les modifier ou les contrôler avec du code et donc de pouvoir les accorder avec les données du modèle.
	
	La gestion des écouteurs se fait grâce au même procédé qui est utilisé pour lier les éléments de l'interface avec la vue sauf que cela créera une méthode au lieu de créer un champ. Voici un exemple d'écouteur :
	
	\begin{verbatim}
		- (void)playerAction:(id)sender {
		    if (sender == playerWhite) {
		        self.editorInformation.colorPlayer = @"white";
		    }
		    else if (sender == playerBlue) {
		        self.editorInformation.colorPlayer = @"blue";
		    }
		    else if (sender == playerRed) {
		        self.editorInformation.colorPlayer = @"red";
		    }
		    else if (sender == playerBlack) {
		        self.editorInformation.colorPlayer = @"black";
		    }
    
		    [editorInformation changeTool:@"player"];
		}
	\end{verbatim}
	
	Pour finir, l'un des principaux point de la gestion de l'\gls{ihm} repose sur le modèle \gls{mvc}. Donc chaque vue doit être associée à un contrôleur.
				
		\subsubsection{Première utilisation}
	C'est au premier lancement de l'application que vont s'initialiser les données sur le mobile.
	Durant celle-ci plusieurs étapes cruciales vont se dérouler. Tout d'abord la
	base de données \gls{sqlite} locale va être créée. Elle sera nécessaire pour les
	comptes utilisateurs mais aussi pour les préférences systèmes et les cartes de jeu.
	Ensuite les ressources nécessaires vont être récupérées depuis le fichier \gls{xml}.
	Elles vont être utilisées pour l'instanciation des objets requis pour le jeu. 
		\begin{center}						
			\includegraphics[scale=0.6]{Developpement/Img/1.eps}
		\end{center}
	Une fois ces étapes réalisées, les cartes du jeu vont être copiées dans
	le répertoire du téléphone. Celles-ci seront des cartes officielles permettant
	de jouer dès le premier lancement.
	
	\subsubsection{Création utilisateur}
	Dès lors que toutes ces initialisations sont achevées avec succès, la page de
	création de compte local est enfin affichée.
		\begin{center}						
			\includegraphics[scale=0.6]{Developpement/Img/2.eps}
		\end{center} 
	Ce dernier est obligatoire afin de pouvoir utiliser l'application. L'utilisateur renseigne son pseudonyme
	pour son profil, qui est ensuite inséré dans la base de données.
	Le menu principal apparaît alors.
	\begin{center}						
			\includegraphics[scale=0.3]{Developpement/Img/3.eps}
		\end{center} 
	
	\subsubsection{Gestion utilisateur}
	A tout moment l'utilisateur a la possibilité d'éditer son profil, qu'il
	soit local ou multijoueur. Cette gestion est une section du menu Option.
		\begin{center}						
			\includegraphics[scale=0.6]{Developpement/Img/5.eps}
			\includegraphics[scale=0.6]{Developpement/Img/6.eps}
		\end{center}
	Pour le profil local il pourra changer de pseudonyme, tout en respectant l'unicité de
	ce dernier dans la base de données, ainsi que de choisir sa couleur de
	personnage. Pour finir il aura le choix de positionner le menu à sa
	guise, suivant qu'il soit gaucher ou droitier.
	
	\subsubsection{Gestion des préférences système}
		\begin{center}						
			\includegraphics[scale=0.6]{Developpement/Img/4.eps}
		\end{center}
	Grâce au menu d'Option, l'utilisateur peut
	modifier le son de l'application ainsi que la langue utilisée dans cette
	dernière.
	
	\subsubsection{Création de carte}
	La création de carte est une fonctionnalité plus qu'interessante puisqu'elle
	vous permet comme son nom l'indique de créer vos propres cartes et de jouer
	dessus. Vous n'aurez pour cela qu'à renseigner un nom de carte non existant. 
	\begin{center}						
			\includegraphics[scale=0.6]{Developpement/Img/10.eps}
			\includegraphics[scale=0.6]{Developpement/Img/11.eps}
		\end{center}
	Il vous sera possible par la suite de les éditer et de les modifier à souhait,
	en laissant libre cours à votre imagination.
	
	
	\subsubsection{Création partie solo}
	La section la plus intéressante concerne bien évidement la création de parties
	locales. Vous aurez la possibilité de configurer ces dernières suivant vos
	attentes. Cette configuration passe par le choix de la carte de jeu, officielle
	ou au préalablement créée, mais aussi la difficulté des adversaires(\gls{bot})
	et leur nombre ainsi que le temps de jeu.
		\begin{center}						
			\includegraphics[scale=0.4]{Developpement/Img/7.eps}
		\end{center} 
	Enfin le type de partie souhaité est lui
	aussi inclus dans les paramètres de jeu. Une fois vos préférences choisies
	vous n'aurez plus qu'à lancer la partie, qui débutera quelques instants après.
	
	
	\subsubsection{Création partie multijoueur}
	Cette section est très proche de la création de parties locales. La seule
	différence notable concerne le choix du nombre d'adversaire. Puisqu'il s'agit
	de parties multijoueurs, les adversaires ne seront pas des \gls{bot} mais bel
	et bien des humains. 
	Là encore dès que vos choix de configurations seront faits, vous pourrez
	choisir de créer la partie. Cette dernière s'initialisera sur le serveur, et ne
	débutera que lorsque le nombre de joueurs requis sera complété. Une page
	d'attente vous sera alors affichée.
	
			

\subsection{Editeur de carte}

	\hypertarget{Editeur de carte}{}
	\label{Editeur de carte}
	
	\subsubsection{Général}
		\paragraph{Moteur de rendu\\}
			Pour modéliser la carte que le joueur est en train de construire, nous avons décidé de la représenter sous forme de deux matrices. 
			
			Tout d'abord la matrice contenant tous les éléments représentant le sol.
			\begin{center}
				\includegraphics{./Developpement/Img/image1.png}
			\end{center}
			Cette première matrice sera dessinée en premier sur la carte.
			
			Ensuite, la deuxième matrice sera déssinée au dessus de la précédente. Elle contient tous les blocs du décor avec lesquels les joueurs pourront intéragir. 
			\begin{center}
				\includegraphics{./Developpement/Img/image2.png}
			\end{center}
			
			Grâce à ces deux matrices, les joueurs pourront à tout moment modifier les éléments de la première ou de la deuxième.
			
			En fusionnant ces deux matrices, nous obtenons la carte complète.
			\begin{center}
				\includegraphics{./Developpement/Img/image3.png}
			\end{center}
			

	\subsubsection{Le modèle}
		La carte est la principale information que l'éditeur de carte doit gérer. Pour représenter une carte, nous avons choisi de la représenter sous la forme de deux matrices ayant les mêmes dimensions que la carte. La première matrice contient des \textit{Object} représentant le sol et la deuxième contient elle aussi des \textit{Object} mais ces derniers représentent des blocs et non le sol. Pour gérer les deux matrices nous avons utilisé des \textit{NSMutableArray} qui sont des tableaux \gls{objective-c} que l'on peut modifier, ils contiennent eux aussi des \textit{NSMutableArray} car il n'existe pas des constructeurs de matrice comme en JAVA. Ensuite l'autre information que la carte doit posséder c'est la position de départ des joueurs. Nous avons utilisé un \textit{NSMutableDictionary} permettant de faire la liaison entre la couleur du joueur et son point de départ. 
			
		Lorsque l'utilisateur a terminé de créer sa carte, il a besoin de la sauvegarder. Pour cela nous avons donc utilisé la sérialisation des objets. Lors de l'enregistrement de la carte un fichier \og .klob \fg  est généré. Ce dernier contient les informations nécessaires pour la reconstruction de la carte. Pour reconstruire une carte, il suffit de désérialiser le contenu du fichier \og .klob \fg correspondant. Pour utiliser la serialisation en 
		\gls{objective-c}, nous avons juste besoin d'implémenter le protocole \textit{NSCoding} qui comporte deux méthode à définir : 
		\textit{- (id)initWithCoder:(NSCoder *)aDecoder} permettant de déserialisé et \textit{- (void)encodeWithCoder:(NSCoder *)aCoder} s'occupant de la serialisation.
	
	\subsubsection{La vue}
		Pour faciliter le développement mais aussi ça réutilisabilité, nous avons découpé la vue de l'éditeur de carte en trois zones. Chacune de ces vues est associée à un contrôleur qui permet de faire la liaison avec le modèle. Pour concevoir les vues nous avons utilisé la classe UIView qui est prévue pour réaliser une interface graphique sur iPhone. 
			
		\begin{center}
			\includegraphics[width=11cm]{./Developpement/Img/carte.eps}
		\end{center}
		Tout d'abord, la vue la plus importante que nous avons créé est la vue affichant la carte. Elle permet au joueur d'intéragir avec celle-ci et de pouvoir créer des cartes selon ses envies. Pour réaliser cette intéraction, nous avons dû surcharger trois méthodes de la classe \textit{UIResponder} : \textit{touchesBegan}, \textit{touchesMoved} et \textit{touchesEnded} permettant de gérer tous les évènements générés lorsque l'utilisateur appuiera sur la vue. La méthode \textit{touchesBegan} permet de récupérer l'évènement lorsque l'utilisateur va appuyer sur la vue, grâce à cette évènement, on peut savoir à quelle position l'utilisateur a appuyé sur l'écran. Ensuite pour récupérer l'évènement lorsque l'utilisateur fais glisser son doigt sur l'écran, il nous suffit d'utiliser \textit{touchesMoved}. Et pour finir lorsque l'utilisateur retire son doigt, nous utilisons la méthode \textit{touchesEnded}. A l'aide de ces trois méthodes, nous avons implémenté les différents gestes que l'utilisateur peut effectuer pour créer une carte. Pour dessiner la carte, nous avons dû surcharger la méthode \textit{- (void)draw:(CGContextRef)context}. Celle-ci permet de modifier le comportement de l'affichage de la vue mais elle donne aussi la possibilité de dessiner n'importe quel objet.
		
		\begin{center}
			\includegraphics{./Developpement/Img/menu_droite.pdf}
		\end{center}
			
		Ensuite, nous avons créé une vue permettant de sélectionner les objets que l'utilisateur peut mettre sur la carte. Cette dernière se trouve à droite de la carte. Dans cette dernière, nous avons des \textit{UIButton} permettant de supprimer des objets ou encore pour changer le type d'objet à placer sur la carte. Mais le plus important dans cette vue est la liste déroulante qui permet de choisir l'objet que l'on veut placer sur la carte. Cette liste déroulante n'étais pas un \gls{widget} de base et nous avons donc dû l'implémenter. La particularité de cette liste est qu'elle est générique, ce qui permet de l'utiliser dans plusieurs cas différents, notamment dans les menus pour afficher le choix des cartes. Grâce à celle-ci l'utilisateur peut changer d'objet selectionné en exerçant un simple mouvement vertical du doigt.
			
		\begin{center}
			\includegraphics[width=11cm]{./Developpement/Img/menu_haut.pdf}
		\end{center}
		Enfin la dernière vue que nous avons réalisé contient plusieurs \textit{UIButton} mais aussi un \textit{UISegmentedControl} qui permet de basculer du mode affichage complet (dessiner tous les éléments de la carte) de la carte, au mode d'affichage partiel (qui affiche que le sol et cache les blocs de la carte), facilitant la modification du sol malgrès les blocs.
			
			
	\subsubsection{Le controlleur}
		
		Le contrôleur est une partie très importante de l'architecture \gls{mvc}, il permet de faire le lien entre les interactions de l'utilisateur sur l'éditeur de carte et les données relatives à celui-ci. Nous avons  donc créé des objets de type \textit{UIViewControler}. Ces derniers nous ont permis de réaliser cette liaison. Grâce à celle-ci, le modèle et la vue sont complètement indépendants ce qui permet de changer de vue sans avoir besoin de modifier le modèle. Comme nous avons divisé l'éditeur de carte en plusieurs sous vues, nous avons donc créé un contrôleur pour chacune d'entre elles. Chacun de ces contrôleurs possède lui-même un contrôleur global qui sera le seul à contacter directement le modèle. Lorsqu'un utilisateur va réaliser une action dans la vue de l'éditeur de carte, cette dernière va appeler une méthode de son contrôleur directe, qui lui appellera une méthode du contrôleur global, qui se chargera d'appeler la bonne méthode du modèle en fonction de l'action effectuée par l'utilisateur. 



\subsection{Jeu}

	\subsubsection{Moteurs}
	
		Au sein d'un jeu vidéo plusieurs types de moteurs sont mis en place.
		Chacun a un travail bien précis.
		Ici nous en trouvons trois au total, à savoir un pour le rendu graphique, un
		pour s'occuper des interactions entre objets (que ce soit des joueurs, des bombes ou autres) dit moteur physique et enfin un dernier gérant
		les actions de l'intelligence artificielle.
		Commençons par le moteur de rendu.
	
		\paragraph{Moteur de rendu\\}
		
			\hypertarget{Moteur de rendu}{}
			\label{Moteur de rendu}
		
			Contrairement à celui que nous avons vu dans la section précédente pour
			l'éditeur de carte
			\footnote{
				\hyperlink{Editeur de carte}{Editeur de carte}
				\og voir section \ref{Editeur de carte}, page \pageref{Editeur de carte}.\fg
			}
			le moteur de rendu se doit d'être beaucoup plus léger. En effet le jeu doit
			dans son ensemble rester le plus fluide possible afin d'offrir à l'utilisateur une meilleure
			expérience. Il faut savoir qu'ici en plus de gérer le rendu, l'application
			doit s'occuper de l'intelligence artificielle
			\footnote{
				\hyperlink{IA}{IA}
				\og voir section \ref{IA}, page \pageref{IA}.\fg
			}.
			, des divers sons
			\footnote{
				\hyperlink{Sons}{Sons}
				\og voir section \ref{Sons}, page \pageref{Sons}.\fg
			} et des interactions entre objets
			 \footnote{
				\hyperlink{Moteur physique}{Moteur physique}
				\og voir section \ref{Moteur physique}, page \pageref{Moteur physique}.\fg
			}..
			qui seront gérés en cours de partie.		
			
			$\,$	
			
			L'utilisateur ne pourra plus modifier la carte et sera
			entièrement dépendant du moteur physique\footnotemark[3]. Par
			exemple un bloc indestructible sera présent tout au long de la
			partie et ne pourra pas être supprimé, il n'est donc plus nécessaire de
			savoir quel type de sol se trouve dessous. De plus comme celui-ci ne peut pas
			être détruit et qu'il n'est pas animé son état sera toujours le même et ne
			correspondra qu'à une seule et unique image.
			
			$\,$			
			
			Un autre exemple est celui d'un sol inanimé tel que l'herbe. Dans le cas où
			il n'y a aucun bloc (destructible) au dessus en début de partie, il en sera
			de même à la fin. Il ne nous est pas nécessaire à chaque
			rafraîchissement de regarder si un bloc existe dessus. Ce test se fait en
			début de partie est sera valide jusqu'à la fin de celle-ci.
			
			
			Cette remarque s'applique sur tous les objets dits \emph{non animés} dont
			l'état ne changera jamais au cours du jeu et seulement eux.
			
			
			Si l'on avait eu un sol animé représentant de l'eau, il aurait été composé de
			plusieurs images et aurait donc necessité un rafraîchissement constant.

			$\,$
			
			Concrètement ce que nous faisons ici à chaque début de partie est de créer
			une image vierge qui aura la taille de la carte affichée sur l'écran dans
			laquelle nous dessinerons tous les objets \emph{non animés}.
			
			$\,$
			
			Pour cela nous allons parcourir les deux matrices définies dans l'éditeur de
			cartes\footnotemark[2] et regarder s'il existe un bloc, si oui est-ce
			qu'il est destructible ?
			
			Si ce bloc est destructible alors il nous est obligatoire de savoir ce qui se
			trouve en dessous.
			Nous allons donc stocker ce bloc dans une table de hachage dont les clefs sont les
			coordonnées de l'objet et dont la valeur est l'objet lui même, et dessiner le
			sol sur l'image citée au dessus.
			
			Si ce bloc est indestructible alors inutile de mémoriser le sol se trouvant
			au dessous.
			
			Sinon s'il n'existe pas de bloc nous allons regarder si le sol est animé. Si
			tel est le cas, alors nous le stockons dans la table de hachage comme un bloc
			destructible, sinon nous le dessinons dans l'image comme un objet inanimé.
			
			$\,$
			
			Voici un exemple concret de la méthode décrite au dessus :
				

			\begin{figure}[!h]			
				\begin{center}			
					\includegraphics[width=229px, height=142px]{Developpement/Img/map.eps}
					\caption{L'image représentant la totalité des objets non animés}
				\end{center}
			\end{figure}
			
			$\,$			

			\begin{figure}[!h]			
				\begin{center}						
					\includegraphics[width=250px, height=250px]{Developpement/Img/hashmap.eps}
					\caption{La hashmap des objets animés}
				\end{center}
			\end{figure}

			$\,$
			
			\newpage

			Les avantages d'avoir utilisé une telle structure sont les suivants. Ici au
			lieu de parcourir les 21*13*2 cases des deux matrices à chaque rafraichissement
			(c'est à dire toutes les 50 millisecondes environ) et d'afficher au minimum
			21*13 objets pour le sol et 64 objets pour les bordures si la carte est vide
			(donc énormement plus si il existe d'autres objets), nous n'affichons qu'une
			image plus au maximum 229 objets.
			
			\begin{center}
				\begin{tabular}{|c|c|c|} \hline
				\multicolumn{3}{c}{Compléxité en nombre d'objet à afficher} \\\hline
				  & Editeur de carte & Jeu    \\\hline 
				Meilleur des cas & 337 & 1    \\\hline
				Pire des cas     & 534 & 229  \\\hline		
				\end{tabular}
			\end{center}
			
			Le meilleur des cas ici décrit une carte vide donc composée que de sol non
			animé ansi que des bordures de la carte. Cela représente dans le nouveau
			moteur de rendu une seule et unique image contrairement à l'ancien où chaque
			objet étant affiché indépendament, ce qui était équivalent à 337 objets.
			
			$\,$
			
			Le pire des cas est une carte remplie au maximum de bloc destructibles,
			obligeant dans les deux cas à connaitre le type de sol se trouvant dessous.
			
			$\,$
			
			Nous voyons très clairement les différences de coûts entre les deux méthodes
			de rendu et l'optimisation qu'engendre la deuxième.
			
			De plus ici l'utilisation de la table de hachage permet dans un premier temps de
			retrouver directement un objet de par ses coordonnées, mais aussi de ne pas
			avoir à parcourir $n$ cases vides comme lors de l'utilisation des matrices.
			Au fur et à mesure de la partie il existera de moins en moins d'objets,
			donc garder une structure aussi grosse qu'une matrice n'est pas optimal.
		
		\paragraph{Moteur physique\\}
		
			\hypertarget{Moteur physique}{}
			\label{Moteur physique}
			
			Un moteur physique est, en informatique, une bibliothèque logicielle 
			indépendante appliquée à la résolution de problèmes de la mécanique
			classique.  Les résolutions typiques sont les collisions, la chute des corps,
			les forces, la cinétique, etc.
			Les moteurs physiques sont principalement utilisés dans des simulations 
			scientifiques et dans les jeux vidéos.
			
			
			Ici notre moteur physique se contentera simplement de s'occuper des diverses
			collisions qu'auront les joueurs avec l'environnement les entourant. Mais
			aussi les intéractions qu'auront les divers objets du décors entre eux
			ainsi qu'avec les joueurs.

			$\,$		
			
			Tout comme le moteur de rendu
			\footnote{
				\hyperlink{Moteur de rendu}{Moteur de rendu}
				\og voir section \ref{Moteur de rendu}, page \pageref{Moteur de rendu}.\fg
			}
			le moteur physique d'un jeu doit être optimal dans les traitements qu'il doit
			effectuer, étant donnée son utilisation permanente au cour du jeu.
			
			
			Afin d'optimiser ces traitements lors des collisions nous avons fusionné les
			deux matrices présentent dans l'éditeur de cartes
			\footnote{
				\hyperlink{Editeur de carte}{Editeur de carte}
				\og voir section \ref{Editeur de carte}, page \pageref{Editeur de carte}.\fg
			}
			afin de n'en obtenir qu'une seule reprenant le principe décrit dans le moteur
			de rendu\footnotemark[2].
			
			$\,$
			
			Cette matrice est composée de sept types d'objets différents à savoir :
			
			\begin{center}
				\begin{tabular}{|c|c|} \hline
				Objet  & Description \\\hline
				EMPTY  & Zone vide représentant un sol quelconque\\\hline
				BLOCK  & Un bloc \\\hline
				GAPE   & Un trou \\\hline
				DAMAGE & Une zone de dommages (piques, lasers, etc \ldots) \\\hline
				DANGEROUS\_AREA & Une zone dangereuse\\\hline
				BOMB & Une bombe\\\hline
				FIRE & Feu résultant de l'explosion d'une bombe\\\hline
				\end{tabular}
			\end{center}
			
			Les zones dangereuses sont les zones qui seront touchées lors de l'explosion
			d'une bombe. Ces zones sont spécifiques à l'intelligence artificielle et leur
			permettent de savoir si elles sont en danger ou non.
			
			
			$\,$
			
			Cette matrice est mise à jour lors de la pose et de l'explosion d'une bombe.
			
			De cette façon il est rapide de savoir si un joueur rentre en collision avec
			un objet quelconque ou si celui-ci subit des dommages.
			
			\subparagraph{Exemple}
			
				\begin{itemize}
				  \item Carte originale :
				  
						\begin{center}						
							\includegraphics[width=115mm,height=71mm]{Developpement/Img/mapcolision_1.eps}
						\end{center}				  		
				  
				  \item Carte de collision :
				  
						\begin{center}						
							\includegraphics[width=115mm,height=102mm]{Developpement/Img/mapcolision_2.eps}
						\end{center}
						
				\end{itemize}
		

			\subparagraph{Déplacements\\}
			
				$\,$
			
				Globalement la gestion des mouvements est identique sur Android comme sur
				iOS.
				Elle consiste à poser le doigt sur l'écran et à le faire glisser dans la
				direction souhaitée. Ainsi le personnage avancera jusqu'à ce que le doigt
				soit relevé.				
				
				Quant à la gestion des collisions bien que chaque équipe utilise la matrice
				décrite ci dessus, les façons de concevoir la chose ont divergé amenant à
				l'élaboration de deux méthodes de rendu. Dans chacune le joueur se deplace
				verticalement, horizontalement ainsi qu'en diagonale.
				
				\begin{enumerate}
				  \item Collisions sous Android
				  
				  		Le principe de collisions sous Android a été conçu de manière à faire
				  		``glisser'' ou non le joueur lorsqu'il rencontre des obstacles.
				  		
				  		
				  		Pour cela nous allons étudier un mouvement qui sera celui vers le haut
				  		afin de mieux comprendre ce terme.
				  		Nous aurions pu prendre n'importe quel autre mouvement cela serait
				  		revenu au même point.
				  		
				  		Il faut juste retenir qu'au mieux le joueur est dans une case et au pire
				  		dans deux et non dans quatre. En effet lors d'un déplacement nous
				  		n'allons regarder que la face correspondant à cette direction comme le montre
				  		l'image ci-dessous:
				  		
				  		$\,$
				  		
						\begin{center}						
							\includegraphics[width=168px,height=84px]{Developpement/Img/ex2.eps}
						\end{center}
						
				  		$\,$				  		
				  		
				  		Le trait vert représente le côté que nous étudierons lors d'un
				  		déplacement vers le haut.
				  		
				  		
				  		Nous partons du principe qu'il n'y a pas de vérification à faire tant
				  		que le joueur ne change pas de case, car du moment où il y est entré
				  		c'est qu'elle est entièrement traversable.
				  		
				  		Il existe donc quatres types de collisions possibles :
				  		
				  		\begin{enumerate}

				  		  \item Le premier cas correspond à celui où les cases sont
				  		  traversables, il n'y a donc qu'à déplacer le joueur vers le haut.

							\begin{center}						
								\includegraphics[width=168px,height=84px]{Developpement/Img/ok2.eps}
							\end{center}

				  		  \item Le second est celui où la ou les cases en face sont des murs, il
				  		  n'y a alors rien à faire, le personnage ne bouge pas.
				  		  				  		  
				  		  	\begin{center}						
								\includegraphics[width=168px,height=84px]{Developpement/Img/ko2.eps}
							\end{center}
							
				  		  \item C'est à partir de ce cas que l'on rencontre le glissement cité
				  		  plus haut.
				  		  Ici le joueur essaie de monter mais la case de gauche correspond à un
				  		  mur. Etant donné la petitesse des écrans et la rapidité à laquelle le
				  		  jeu se déroule il serait embêtant pour l'utilisateur de devoir se
				  		  décaler à droite de façon à être bien en face de la case libre.
				  		  Nous avons donc pris en compte le cas où le joueur aurait dépassé la
				  		  moitié du bloc intraversable. Dans ce cas là nous le faisons glisser
				  		  sur la droite de façon à ce que celui-ci se place convenablement en
				  		  face de la case et monte normalement.
				  		  
				  		  	\begin{center}						
								\includegraphics[width=84px,height=84px]{Developpement/Img/ko3.eps}
							\end{center}
				  		  
				  		  \item Le dernier cas est l'opposé du précédent et fonctionne de la
				  		  même manière.
				  		  
				  		  	\begin{center}						
								\includegraphics[width=84px,height=84px]{Developpement/Img/ko4.eps}
							\end{center}
				  		  
				  		\end{enumerate}

				  
				  \item Collisions sous iOS
				
				Le principe des collisions sous \gls{ios} a été réfléchi de manière a ce que les
				déplacements soient fluides et que les collisions avec des blocs ne
				freinent pas la fluidité du jeu. Car en effet lors des collisions, 
				si le joueur doit passer entre deux blocs, 
				celui-ci doit passer au pixel prêt. Cela implique que l'utilisateur doit
				être très minutieux dans ses déplacements et cela rend le jeu casiment
				injouable lors de passage entre deux blocs. 
				Donc pour remédier à ce problème nous avons décidé d'établir un système de marge sous \gls{ios}.
				C'est à dire que lors de la collision avec un bloc. 
				On va vérifier si au moins un pixel du joueur touche au moins un pixel du
				bloc moins une marge. 
				Voici le tout en image:

				Il faut donc que le rectangle rouge entourant 
				le joueur ne touche aucun autre rectangle rouge entourant
				les blocs, pour que le joueur puisse se déplacer. Les rectangles délimitant
				les blocs sont réduits grâce à la marge (fleche jaune) pour permettre à
				l'utilisateur de passer facilement.
				
				$\,$
				  		
				\begin{center}						
			%		\includegraphics[width=168px,height=84px]{Developpement/Img/mouvementCollision.pdf}
				\end{center}
						
				$\,$	
				
				
				\end{enumerate}
			
	
	
